## IV. Backing services
### Tratar a los "backing services" como recursos conectables

Un *backing service* es cualquier recurso que la aplicación puede consumir a través de la red como parte de su funcionamiento habitual. Entre otros ejemplos, podemos encontrar bases de datos (como [MySQL](http://dev.mysql.com/) o [CouchDB](http://couchdb.apache.org/)), los sistemas de mensajería y de colas (como [RabbitMQ](http://www.rabbitmq.com/) o [Beanstalkd](https://beanstalkd.github.io)), los servicios SMTP de email (como [Postfix](http://www.postfix.org/)), y los sistemas de cache (como [Memcached](http://memcached.org/)).

Tradicionalmente, los "backing services" (como las bases de datos) han sido gestionadas por los mismos administradores de sistemas que despliegan la aplicacion en producción. Además de esos servicios gestionados localmente, las aplicaciones también pueden usar servicios proporcionados y gestionados por terceros, como por ejemplo los servicios SMTP ([Postmark](http://postmarkapp.com/)), los servicios de recopilación de métricas (como [New Relic](http://newrelic.com/) o [Loggly](http://www.loggly.com/)), los servicios de activos binarios (como [Amazon S3](http://aws.amazon.com/s3/)), e incluso servicios que se consumen accediendo a ellos mediante un API (como [Twitter](http://dev.twitter.com/), [Google Maps](https://developers.google.com/maps/), o [Last.fm](http://www.last.fm/api)).

**El código de una aplicación "twelve-factor" no hace distinciones entre servicios locales y de terceros.** Para la aplicación, ambos son recursos conectados, accedidos mediante una URL u otro localizador o credencial almacenado en la [config](./config). Un [despliegue](./codebase) de una aplicación "twelve-factor" debería ser capaz de reemplazar una base de datos local MySQL por una gestionada por un tercero (como [Amazon RDS](http://aws.amazon.com/rds/)) sin ningún cambio en el código de la aplicación. Igualmente, un servidor SMTP local se podría cambiar por un servicio de terceros (como Postmark) sin modificaciones en el código. En ambos casos, solo el manejador del recurso necesita cambiar en la configuración.

Cada "backing service" distinto es un *recurso*. Por ejemplo, una base de datos MySQL es un recurso; dos bases de datos MySQL (usadas para "sharding" en la capa de aplicación) les convierte en dos recursos distintos. Una aplicación "twelve factor" trata esas bases de datos como *recursos conectados*, lo que demuestra su bajo acoplamiento al despliegue al que se unen.

<img src="/images/attached-resources.png" class="full" alt="Un despliegue en producción conectado a cuatro backing services." />

Los recursos se pueden conectar y desconectar a voluntad. Por ejemplo, si la base de datos funciona mal debido a un problema en el hardware, el administrador de la aplicación puede cambiar a un nuevo servidor de bases de datos que haya sido restaurado de un backup reciente. La base de datos actual de producción se puede desconectar, y conectar una nueva base de datos sin tener que cambiar nada en el código.
